ARL-TR-8043  JUN  2017 


ARL 

US  Army  Research  Laboratory 


OpenFlow  Extensions  for  Programmable 
Quantum  Networks 


by  Venkat  Dasari,  Nikolai  Snow,  Billy  Geerhart,  and  Sam 
Snodgrass 


Approved  for  public  release;  distribution  is  unlimited. 

! 


NOTICES 

Disclaimers 

The  findings  in  this  report  are  not  to  be  construed  as  an  official  Department  of  the 
Army  position  unless  so  designated  by  other  authorized  documents. 

Citation  of  manufacturer’s  or  trade  names  does  not  constitute  an  official 
endorsement  or  approval  of  the  use  thereof. 


Destroy  this  report  when  it  is  no  longer  needed.  Do  not  return  it  to  the  originator. 


ARL-TR-8043  •  JUN  2017 


ARL 

US  Army  Research  Laboratory 


OpenFlow  Extensions  for  Programmable 
Quantum  Networks 


by  Venkat  Dasari,  Nikolai  Snow,  and  Billy  Geerhart 

Computational  and  Information  Sciences  Directorate,  ARL 

Sam  Snodgrass 

Drexel  University,  Philadelphia,  PA 


Approved  for  public  release;  distribution  is  unlimited. 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
0MB  No.  0704-0188 


Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and  maintaining  the 
data  needed,  and  completing  and  reviewing  the  collection  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including  suggestions  for  reducing  the 
burden,  to  Department  of  Defense,  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports  (0704-0188),  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302. 
Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  any  penalty  for  failing  to  comply  with  a  collection  of  information  if  it  does  not  display  a  currently 
valid  0MB  control  number. 

PLEASE  DO  NOT  RETURN  YOUR  FORM  TO  THE  ABOVE  ADDRESS. 


12.  DISTRIBUTION/ AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  is  unlimited. 

13.  SUPPLEMENTARY  NOTES 


14.  ABSTRACT 

Networks  are  essential  for  both  quantum  and  classical  systems  for  transporting  information  between  network  nodes.  Networks 
define  abstractions  and  interfaces  required  for  establishing  stable  communication  frameworks  required  for  network  applications 
to  communicate.  Advances  in  network  protocols  and  architectures  have  led  to  the  development  of  software-defined 
programmable  networks.  Previously,  the  feasibility  of  extending  programmable  network  principles  to  build  multinode  quantum 
networks  has  been  described.  This  project  built  upon  a  previously  described  programmable  quantum  network  model  to  leverage 
new  optical  labels  in  the  latest  OpenFlow  protocol  to  manage  optical  channels  and  lambda  switching.  Custom  modifications  to 
the  OpenFlow  protocol  base  code  were  developed  to  create  new  labels  for  managing  the  optical  channels  associated  with 
quantum  networks.  Additionally,  the  OpenFlow  match/action  tables  were  modified  to  recognize  and  take  action  on  new 
OpenFlow  labels  related  to  the  quantum  network  attributes. 

15.  SUBJECT  TERMS 

quantum,  teleportation,  OpenFlow,  controller,  metadata 

17.  LIMITATION  18.  NUMBER 
OF  OF 

ABSTRACT  PAGES 

UU  16 

Standard  Form  298  (Rev.  8/98) 
Prescribed  by  ANSI  Std.  Z39.18 


19a.  NAME  OF  RESPONSIBLE  PERSON 

Venkat  Dasari 

19b.  TELEPHONE  NUMBER  (Include  area  code) 

410-278-2846 


16.  SECURITY  CLASSIFICATION  OF: 


a.  REPORT 

b.  ABSTRACT 

c.  THIS  PAGE 

Unclassified 

Unclassified 

Unclassified 

1.  REPORT  DATE  (DD-MM-YYYY) 

2.  REPORT  TYPE 

June  2017 

Technical  Report 

4.  TITLE  AND  SUBTITLE 

OpenFlow  Extensions  for  Programmable  Quantum  Networks 


6.  AUTHOR(S) 

Venkat  Dasari,  Nikolai  Snow,  Billy  Geerhart,  and  Sam  Snodgrass 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

US  Army  Research  Laboratory 
ATTN;  RDRL-CIH-S 

Aberdeen  Proving  Ground,  MD  21005-5067 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 


3.  DATES  COVERED  (From  -  To) 

June  2015-March  2017 

Sa.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

Sc.  PROGRAM  ELEMENT  NUMBER 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

8.  PERFORMING  ORGANIZATION  REPORT  NUMBER 

ARL-TR-8043 

10.  SPONSOR/MONITOR'S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT  NUMBER(S) 


11 


Contents 


List  of  Figures  iv 

1.  Introduction  1 

2.  Background  1 

2.1  Quantum  Networks  2 

2.2  Software- Defined  Networks  3 

3.  Approach  3 

3.1  Metadata  4 

3.2  Switch  4 

3.3  Controller  5 

3.4  WireShark  5 

4.  Results  6 

5.  Conclusions  and  Future  Work  6 

6.  References  8 

Distribution  List  9 


Approved  for  public  release;  distribution  is  unlimited. 

iii 


List  of  Figures 


Fig.  1  Quantum  teleportation  using  quantum  circuits.  The  gamma  photon  on 
the  left  is  teleported  to  the  right  using  both  the  quantum  and  classical 
channel . 2 

Fig.  2  Symmetric  key  distribution  using  a  quantum  and  classical  channel 

working  together  using  OpenFlow . 3 

Fig.  3  A  snippet  of  code  from  the  OpenVSwitch  code  base  where  we 

added  a  new  field  corresponding  to  the  quantum  channel . 4 

Fig.  4  A  code  snippet  from  the  Ryu  code  base  showing  the  parsing  function 

we  wrote  for  one  of  our  new  labels . 5 

Fig.  5  WireShark  output  showing  our  custom  qchannel  label . 6 


Approved  for  public  release;  distribution  is  unlimited. 


IV 


1.  Introduction 


Quantum  networks  and  quantum  computing  have  been  receiving  a  surge  of  interest 
recently.  However,  there  has  been  little  development  of  network  abstractions  to 
allow  for  communication  between  the  quantum  and  classical  components  of  a 
quantum  network.  We  are  interested  in  developing  these  abstractions  by  extending 
OpenFlow,  which  is  a  well-known  software-defined  network  (SDN)  protocol. 
Defining  software-defined  quantum  networks  has  been  proposed  previously,^  and 
important  quantum  metadata  attributes  that  need  to  be  passed  between  the  quantum 
and  classical  channels  have  been  defined.^  We  build  upon  these  previous  works  by 
extending  the  OpenFlow  protocol  to  recognize  the  metadata  labels  within  packets 
and  to  match  on  those  labels  to  route  the  packets  accordingly. 

In  the  remainder  of  the  report  we 

1 )  formulate  the  specific  problem  we  are  trying  to  address, 

2)  give  a  brief  introduction  to  the  work  that  has  previously  been  performed  on 
this  topic, 

3 )  outline  our  approach  for  addressing  the  stated  problem, 

4)  discuss  the  results  of  our  approach,  and 

5)  draw  conclusions  and  indicate  plans  for  future  extensions  to  this  work. 

We  are  addressing  the  problem  of  communication  between  quantum  and  classical 
channels  within  a  quantum  network.  Quantum  applications  generally  require  the 
synchronized  transfer  of  information  through  both  the  quantum  and  classical 
channel.  However,  currently  there  are  no  standard  communication  protocols  for 
communication  between  these  channels.  To  address  this  issue,  we  extend  the 
OpenFlow  protocol  with  additional  fields  corresponding  to  quantum  metadata  that 
can  be  passed  between  the  quantum  and  classical  channels  to  facilitate  quantum 
applications. 

2.  Background 

In  this  section  we  give  a  brief  introduction  to  quantum  networks  before  briefly 
discussing  SDNs. 
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2.1  Quantum  Networks 


Quantum  networks  are  composed  of  a  set  of  quantum  systems  connected  via 
quantum  communication  channels^  and  a  set  of  classical  systems  connected  via 
classical  communication  channels.  These  networks  differ  from  standard  classical 
networks  by  their  use  of  quantum  physical  phenomena  to  achieve  network 
functionalities  on  the  quantum  channels,  such  as  encoding,  transmitting,  and 
decoding  information.’  Specifically,  quantum  nodes  communicate  using  entangled 
particles  and  perform  calculations  using  quantum  logic  gates.  Additionally,  quantum 
computing  uses  a  quantum  bit  (qubit)  as  its  basic  unit  of  computation,  which  exists 
in  a  probabilistic  complex  vector  space  where  each  qubit  can  be  in  a  superposition 
of  values,  whereas  classical  computing  uses  bits  from  a  discrete  Boolean  state 
space  as  its  basic  unit  of  computation.  These  differences  make  communication 
between  the  quantum  and  classical  channels  very  difficult.  However,  communication 
between  these  channels  is  required  for  the  transmission  of  important  quantum 
metadata  needed  for  quantum  applications,  and  Dasari  and  Humble^  have 
previously  defined  the  metadata  attributes  that  are  required  for  a  quantum  network. 
The  current  work  extends  theirs  by  adding  the  attributes  to  the  OpenFlow  protocol 
for  software-defined  networks,  allowing  for  the  transmission  of  those  attributes 
throughout  our  emulated  network  and,  therefore,  communication  between  the 
classical  and  quantum  channels  (Figs.  1  and  2). 


Fig.  1  Quantum  teleportation  using  quantum  circuits.  The  gamma  photon  on  the  left  is 
teleported  to  the  right  using  both  the  quantum  and  classical  channel. 
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Fig.  2  Symmetric  key  distribution  using  a  quantum  and  classical  channel  working  together 

using  OpenFlow 

2.2  Software-Defined  Networks 

SDNs  differ  from  standard  networks  by  separating  the  eontrol  and  data  plane  of 
the  network.  That  is,  while  in  a  standard  network  each  switch  has  its  own  control 
intelligence,  in  an  SDN  the  control  intelligence  is  removed  from  the  switches  and 
placed  in  a  centralized  controller.  This  forces  the  switches  to  act  as  forwarding 
devices,  while  the  centralized  intelligence  installs  logic  into  the  switches  as 
needed.^  The  controller  itself  can  service  many  switches,  which  allows  the 
controller  to  build  a  global  view  of  the  network;  therefore,  more-informed  and 
more-intelligent  behavior  can  be  implemented. 

SDNs  have  previously  been  proposed  for  use  with  quantum  networks.^  SDN 
principles  applied  to  a  quantum  network  allow  for  easier  communication  between  the 
classical  and  quantum  components;  in  particular,  abstractions  can  be  defined  within 
the  networking  protocols  to  allow  for  such  communications,  and  logic  can  be  easily 
installed  onto  the  controller  to  handle  those  communications  appropriately. 
OpenFlow  is  a  widespread  protocol  that  adheres  to  SDN  principles  and  is  commonly 
used  to  develop  such  networks.^ 

3.  Approach 

SDN  principles  allow  for  a  programmable  control  plane  from  which  a  network 
operating  system  (OS)  can  be  made.  The  network  OS  can  be  used  to  coordinate  the 
synchronized  transfer  of  information  across  disparate  communication  channels. 
This  is  especially  useful  when  trying  to  build  a  standardized  communication 
protocol  to  allow  the  quantum  and  classical  channels  to  work  together. 
Synchronizing  the  quantum  and  classical  channels  requires  the  introduction  of  new 
quantum  metadata  attributes  at  the  packet  level,  which  also  requires  changes  in  the 
software  at  the  switch  and  controller  level  (Fig.  3). 
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305  /*  "qchannel". 

306  * 

307  *  Experimental  attribute. 

308  * 

309  *  Type:  be32. 

310  *  Maskable:  no. 

311  *  Formatting:  hexadecimal. 

312  *  Prerequisites:  none. 

313  *  Access:  read/write. 

314  *  NXM:  none. 

315  *  OXM:  NXOXM_ET_QCHANNEL(40)  since  0F1.3  and  v2.5. 

316  */ 

317  MFFQCHANNEL, 


Fig.  3  A  snippet  of  code  from  the  OpenVSwitch  code  base  where  we  added  a  new  field 
corresponding  to  the  quantum  channel 


3.1  Metadata 

Quantum  metadata  specifying  parameters  and  protocols  for  the  quantum  channel  and 
application  is  required  for  quantum  applications  to  run  on  a  quantum  network. 
The  metadata  attributes  that  we  added  to  OpenFlow  are  several  of  those  proposed 
and  defined  by  Dasari  and  Humble.^  Specifically,  we  added  the  following  labels: 

•  QCHANNEL:  a  unique  identifier  for  the  quantum  channel  for  which  the  rest  of 
the  metadata  applies  (i.e.,  which  channel  communications  and  quantum 
applications  will  be  performed) 

•  QCOM:  a  unique  identifier  for  the  quantum  application  to  be  performed  (e.g., 
quantum  key  distribution  or  teleportation) 

•  QEC :  a  unique  identifier  for  the  quantum  error  correction  protocol  to  be  used 
for  detecting  and  correcting  errors. 


3.2  Switch 

In  an  SDN,  switches  function  as  fast-forwarding  devices  with  no  internal 
intelligence  of  their  own.  However,  the  switches  still  need  to  be  able  to  recognize 
the  labels  or  attributes  of  the  incoming  packets  in  order  to  route  them  according  to 
the  logic  installed  by  the  controller. 

We  chose  OpenVSwitch^®  as  our  switch  mostly  because  of  its  widespread  use  and 
support  as  well  as  its  inclusion  in  the  Mininet  network  emulator.  The  main  drawback 
of  OpenVSwitch  is  that  it  is  an  enormous  code  base  (comprising  hundreds  of  files 
and  hundreds  of  thousands  of  lines  of  code).  As  a  result,  ensuring  consistency 
throughout  the  code  base  is  a  challenge.  Additionally,  though  there  is  a  fairly  large 
community,  there  has  not  been  much  work  in  adding  new  fields  to  the  code  base, 
resulting  in  only  a  small  amount  of  documentation  and  guidance  for  this  task. 
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Despite  these  setbacks  we  were  able  to  define  our  labels  in  OpenVS witch  and 
achieve  consistency  throughout  the  code  base,  allowing  us  to  recognize  our  labels 
and  send  packets  with  our  labels  on  to  the  controller.  Figure  3  shows  one  place  we 
added  our  labels. 


3.3  Controller 


In  an  SDN  the  controller  contains  all  of  the  intelligence  of  the  network.*  When  a 
switch  encounters  a  packet  it  does  not  know  how  to  route,  it  forwards  it  to  the 
controller,  which  decides  what  should  be  done  with  the  packet.  Furthermore, 
the  controller  will  install  that  logic  onto  the  switch  so  that  the  switch  will  know 
what  to  do  the  next  time  a  similar  packet  arrives. 

We  chose  Ryu'*  as  our  controller  for  2  reasons:  Mininet  easily  interfaced  with 
Ryu,  and  of  all  the  controllers  we  investigated,  Ryu  appeared  to  be  the  most 
straightforward  to  add  new  label  capabilities.  To  add  our  labels  to  Ryu,  we  needed 
to  define  the  labels  as  well  as  functions  for  parsing  our  new  labels.  Figure  4  shows 
the  functions  we  created  for  one  of  our  new  labels.  After  adding  our  labels  and  parsing 
functions,  we  are  able  to  see  our  labels  and  values  within  the  controller  as  well  as  being 
passed  between  the  switch  and  controller  using  WireShark. 


2308  class  NXActionQCHANNEKNXAction) : 

2309  _subtype  =  nici ra_ext . NXAST_QCHANNEL 

2310 

2311  #  OCHANNEL 

2312  fmt_str  =  ' !!' 

2313 

2314  def  _ init _ {self, 

2315  OCHANNEL, 

2316  type_=None,  len_=Nor)e,  experinienten=None,  subtype=Honeh 

2317  super(NXActionQCHANNEL,  self). _ init () 

2318  self.qchannel  =  QCHANNEL 

2319 

2320  (aclassmethod 

2321  def  parser{cls,  but): 

2322  (QCHANNEL)  =  struct. jnpack_from( 

2323  cls.fmtstr,  buf,  0) 

2324  return  els (QCHANNEL) 

2325 

2326  def  serialize  body (self) : 

2327  data  =  bytearrayO 

2328  insg_pack_into(self .  fmt  str,  data,  0, 

2329  self.qchannel) 

2330  return  data 


Fig.  4  A  code  snippet  from  the  Ryu  code  base  showing  the  parsing  function  we  wrote  for  one 

of  our  new  labels 


3.4  WireShark 

To  verify  that  the  packets  being  sent  through  the  network  contain  our  new  labels,  we 
used  the  packet  sniffing  tool  WireShark.'^  However,  our  labels  are  not  present  in 
standard  packets,  so  we  modified  a  plugin  for  WireShark,  allowing  it  to  parse  and 
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display  our  labels  when  it  encountered  them  in  a  packet.  Using  Wireshark,  we 
could  see  a  packet  with  one  of  our  labels  traveling  from  the  switch  to  the  controller 
(Fig.  5). 


►Internet  Protocol  Versi 
►  TranwijslonControl-  Pr 
r OpenFlow  (LOXI) 

on  4,  Src:  127. t 
otocol ;  Src  Por 

.9.1  (127.9.6.1 
:  47848  f47848) 

1,  Dst:  127.9.6. 
Ost  Port:  open 

1  (127.9.6.1) 
flota  (6653),  Se< 

|r  2869,  Ack;  23 

99,  ten:  126 

versioh:  i 

type:  OfPT  PACKET  IN 
lengths  126 
xld;  6- 

19) 

buffer; id:  4294967295 
total  ten:  79 
reason;  OFPR  NO  HATCH 
table  id:  6 
cookie:  6 

.w.A,f.aAtfh . 

(9) 

. 

type:;0FPf1T  OXM  (1) 
length:  24 

TOf  oxfi  list 

▼  of  oxB  qchannel 

type  len:  4294922248 

experimenter  id:  8992 
value:  9 

Fig.  5  WireShark  output  showing  our  custom  qchannel  label 


4.  Results 


After  extensive  modifications  to  OpenVSwitch  and  adding  our  labels  and  parsing 
capabilities  to  Ryu,  we  were  able  to  send  and  recognize  packets  between  the  switch 
and  controller.  Furthermore,  we  were  able  to  verify  this  claim  by  modifying 
WireShark  to  be  able  to  recognize  our  labels.  Achieving  this  transmission  of  new 
labels  between  the  switch  and  controller  is  a  promising  result,  as  it  shows  that  our 
quantum  metadata  labels  are  able  to  be  passed  through  the  network  allowing  for 
communication  between  the  quantum  and  classical  channels,  which  will  facilitate 
quantum  applications  and  make  communication  on  the  quantum  channel  more 
reliable. 

5.  Conclusions  and  Future  Work 


In  this  report  we  discussed  our  approach  for  enabling  communication  between  the 
quantum  and  classical  channels  within  a  quantum  network.  We  accomplished  this 
by  extending  the  OpenFlow  protocol  to  allow  for  additional  quantum  metadata 
labels,  corresponding  to  necessary  information  about  the  quantum  channel  and 
quantum  applications,  to  be  transmitted  through  the  network.  Standardized 
communication  between  the  quantum  and  classical  channels  eases  the  process  of 
developing  quantum  applications  by  removing  the  burden  of  achieving  that 
communication  from  the  developer.  Additionally,  these  communications  will  allow 
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for  more-reliable  communications  between  the  quantum  channels  by  setting  up  the 
quantum  channels  and  networking  environment  before  the  important  data  are 
transmitted. 

In  the  future  we  plan  to  extend  this  work  by  allowing  a  nonswitch  node  to  send  a 
packet  containing  the  quantum  metadata  labels  to  the  switch  and  have  it  routed 
appropriately.  We  are  also  planning  to  apply  our  framework  to  a  physical  multinode 
quantum  network  after  more  testing  is  completed  in  our  emulated  environment. 
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